Prerequisites for the Nodinite Azure Logic Apps Logging and Monitoring Agent
Info
This page describes the prerequisites to successfully install and run the Nodinite Azure Logic Apps Log and Monitoring Agent and you will enjoy a plug-and-play experience for Logic Apps Monitoring and Logic Apps Logging.
Before you dig in and enable the built-in Azure Logic Apps tracking feature, please read the About Logic Apps Logging options user guide first.
Monitoring
The Nodinite Azure Logic Apps Log and Monitoring Agent features Azure Monitoring without the need for many costly (consultancy hours) time-consuming hands-on tweaks featured in the Azure portal.
The Nodinite Azure Logic Apps Log and Monitoring Agent often replace Azure Monitoring!
Logging and/or failed runs Monitoring
To enable Logging and the Monitoring of failed runs from Workflows, the Agent makes use of the following Azure services:
- Enable Logging in Workflows
- An Azure Event Hub (target for diagnostics Logging).
- You can use one or more Event Hub entities as the target.
- A storage container to keep track of the current checkpoint.
- Each Event Hub Entity must have its unique container to store the bookmark (checkpoint).
Important
You must have one unique storage container per Event Hub entity! Otherwise, you will overwrite the checkpoint, thus preventing the operational Logging feature.
- The Agent makes use of a mandatory SQL Server Agent Database. This database boosts performance and provides long-term statistics. Every instance of the Agent requires its unique database.
You can install instances of this Agent on-premise using TCP/IP for local network access and/or in the cloud/off-site using Service Bus Relaying (see also the external link for additional information 'Azure Relay FAQs') as long as the Agent can access the Nodinite Log API.
We recommend that you keep this Agent close to the Nodinite Core Services. This documentation covers a local network setup (usually on the Nodinite application server).
Software Requirements
The Nodinite Azure Logic Apps Log and Monitoring Agent is a Windows Service you usually install on the Nodinite application server.
| Product | |
|---|---|
| Windows Server | Windows 2025Windows 2022Windows 2019Windows 2016Windows 2012 R2Windows 2012 |
| .NET | .NET 10.0 – Install the Hosting Bundle (includes .NET Runtime and ASP.NET Core Runtime) New 7.3.9 From v7.3.9 this agent runs on .NET 10. Prior versions (v6.1.29–v7.3.8) required .NET 9.0. |
| DACFX | Download You must use 16.1 or later |
Important
This agent is updated timely to comply with the Microsoft support policy. You must regularly patch your .NET and .NET Core environments, please review the NET and .NET Core Support Policy
Supported Versions
Cloud technologies are evolving fast, and Microsoft deprecates older versions of their APIs now and then. Nodinite will always support the APIs supported by Microsoft. This means you need to update Nodinite and our Azure Logic Apps Log and Monitoring Agent from time to time.
Make sure to subscribe to our Release Notes.
What Azure User rights do the Azure Logic Apps Logging and Monitoring Agent require?
The Agent always uses an App Registration (Application/Client) to authenticate with the Azure REST API for subscription discovery, monitoring, and remote actions. Carefully read and follow the instructions detailed in the Azure Applications Access user guide.
Review and apply least-privilege role assignments from AzureApplicationsAccess - Least Privileges.
Azure REST API access
- Subscriptions - Reader (inherits to all resources)
Logic Apps
- Logic App Operator - Enable/Disable Logic App. This role is NOT allowed to Resubmit runs
- Logic App Contributor - Allow to Resubmit runs. If you assign membership with this role; The Client does not need to be a member of the Logic App Operator role
Event Hubs
- Azure Event Hubs Data Receiver New 6.1.29
- Event Hub Connection string (SAS, optional and not recommended as this cannot be used when local authentication is disabled) New 6.1.29
Storage Account
- Storage Blob Data Contributor New 6.1.29 (recommended)
- Storage connection string (SAS, optional) - This option is not recommended.
Enable Logic Apps Logging in Azure
To enable Logging to Nodinite from your Logic Apps, you must enable and configure some features in the Azure portal. You can always script, and use ARM Templates to create the necessary services and apply the proper settings. The Nodinite Azure Logic Apps Log and Monitoring Agent requires information about these configurations.
The following Azure services and settings are required to enable Logging to Nodinite from Azure Logic Apps:
Configure each Logic Apps Diagnostic setting with the 'Workflowruntime' Logging option (Standard and Consumption)
Please review the ARM Template user guide for an example to use with your build and deployment process.
Storage account - Stores the checkpoint (offset position in the Event Hub stream). You must use one unique configuration per event hub entity.
The Event Hub "only" supports client-side checkpointing.
Event Hub entity - Match according to the diagnostics settings in Azure. The Agent can tap many event hubs simultaneously. This means that you can consider the geo-redundancy, the number of partitions to use, and the retention.
Event Hub Entity
The Azure Event Hub entity is used as the target for Logging when the diagnostics logging for a Logic App is enabled.
Note
The different diagnostic settings can target a single or multiple Event Hubs. You must match these different settings with the configuration within the Nodinite Azure Logic Apps Log and Monitoring Agent.
- Use one or more dedicated event hubs entities for the Logic Apps Logging. This is set in the Azure diagnostic settings.
Important
If you use diagnostic Logging also for other Azure resources like API Management Services, then you must provide a different set of Event Hub Entities (names) for the different type of Azure resources
- You can use multiple Event Hubs for different diagnostic settings
- Access Control (Shared Access Policy)
- Use at least 2 partitions, see note below:
Important
For high volume solutions (>2.000.000 events per day), you might need to [re]-create the Event Hub with 4 (or even more partitions).
- Try to keep the number of Event Hub entities as small as possible
You can re-use the same Event Hub entity from many diagnostic settings set on the Azure Logic Apps.
- You must use an Event Hub in the same region as your Logic Apps.
Here's an example of an Azure Event Hub entity in use to enable the Azure Logic Apps Logging feature.
Details about the Azure Event Hub entity.
Data is updated regularly on the Event Hub.

Additional comments about the Event Hub
The target for Logging from the Azure Logic App is an Event Hub entity. These named Event Hubs entities MUST be unique for Logging from Azure Logic Apps.
- Logging from Azure functions can share the same Eventy Hub if the content logged is a Nodinite JSON Log Event.
- Since the content is in a different format; the Logging from Azure Logic Apps requires one or more OTHER event hubs as the target.
Using a shared Event Hub for a Nodinite JSON Log Event has the advantage of less administration (i.e. you must configure the Nodinite Pickup Log Events Service Logging Agent to fetch these events) The disadvantage with a shared event hub entity can be performance-related, or other factors to consider like pricing (Logging from multiple regions), scalability, retention settings, number of partitions, ...
Tip
Make sure to use separate event hub entities for different purposes and needs, i.e. multiple Logic App Logging, multiple API Management Services, multiple APIs, and multiple Azure functions, all according to your architecture.
Reduce Azure retention and lower TCO
Azure run-history retention and Event Hub diagnostic retention are covered in the dedicated Azure Logic Apps + Nodinite: Reduce Observability TCO article. That page explains the retention model, Event Hub sizing, checkpoint storage, and why Nodinite can keep the long-term integration history while Azure stays on a shorter operational window.
If you are configuring the agent for the first time, keep this page focused on prerequisites and use the TCO article when you need the retention strategy details.
What Windows User Rights does the Azure Logic Apps Logging and Monitoring Agent require?
The Agent is installed as a Windows Service usually on the Nodinite application server. Virtual machines are supported.
- Local named account or domain account (preferred).
- Access and run-time rights.
- Follow the 'How to set logon as a Windows service right' user guide for detailed instructions.
What SQL Server rights does the Azure Logic Apps Logging and Monitoring Agent require?
The Agent requires access to a SQL Server Monitoring Database for performance optimization and long-term statistics storage. The Windows Service account running the Agent must have the following SQL Server permissions:
Required SQL Server rights
On the SQL Server instance with the Monitoring Database, the service account must have the following User Mapping:
- db_owner - Required for both installation/updates and runtime operations. The Agent automatically updates the database schema during startup when new versions are deployed.
Tip
For detailed instructions on installing and configuring the Monitoring Database, connection strings, and troubleshooting, see the comprehensive Agent Database guide.
What Firewall settings and connectivity checks are required for the Azure Logic Apps Logging and Monitoring Agent?
The detailed firewall matrix now lives in the Troubleshooting guide. Use that page when the agent cannot reach Azure, the Log API, the Monitoring Database, or the Storage Account.
The troubleshooting page covers:
- Monitoring Service to agent connectivity for v7 IIS-hosted and legacy v6 deployments
- Azure Management API access on 443
- Event Hub access on 443, 5671/5672, and 9350-9354
- Azure Storage access on 443
- Nodinite Log API access on 80 and 443
- SQL Server access on 1433
- DNS and stateful firewall behavior
For a fast fix, start with AMQP Port Configuration - 5671 and 5672 if Event Hub connectivity is the issue, and Safelist the Azure portal URLs on your firewall or proxy server if Azure portal access is blocked.
If the agent and Log API are on the same server, HTTP is usually the fastest option because the traffic stays local.
Frequently asked questions
Additional solutions to common problems and the FAQ for the Nodinite Azure Logic Apps Logging and Monitoring Agent exist in the Troubleshooting user guide.
Next Step
Install the Azure Logic Apps Logging and Monitoring Agent
Related Topics
Add or manage a Monitoring Agent Configuration Monitoring Agents Administration